Subject: Re: The Infamous GOTO
From: Erik Naggum <[email-masked]>
Date: 25 Apr 1994 02:03:17 +0200
Newsgroups: comp.programming

the condemnations of GOTO are based on the idea that programming a computer
can be done without reference to or understanding of the actual computer
being programmed and the less the programmer knows about the hardware, the
better.  this is obviously false, and teaching this to wanna-be programmers
is possibly the single worst offense against their intellect, their future
career, and the against the software industry as a whole.

my tenet is that a programmer who is unable to read the assembly language
for any given processor on which he programs, does not know what is going
on, and should not be programming, any more than an architect who has no
knowledge of actual structures or buildings should not design them.  (other
aspects of engineering disciplines may or may not apply.)

the belief that GOTO leads to "spaghetti code" is equally obviously false.
just because you _can_ do something, doesn't mean you will, or have to.

GOTO is not alone, however.  for instance, the C "break", "continue", and
"return" statements are all variations on the GOTO theme, and allow exit
from control structures to be more precisely stated than alternatives like
setting variables that control the looping (thus introducing details of the
loop behavior where it does not belong) and else'ing through enormous "if"
statements (thus introducing mental overhead in reading the code), to
mention two specific examples.

the extremely tiresome thread "REPEAT NO MORE" mentioned in its beginning
some of the alternatives to loop control structures, and the need for a
variety of them to support a variety of actual programming needs became
obvious to most of the readers.  some languages allow labeled loops and an
"exit" statement to exit a particular loop (Ada), which is just another
GOTO in disguise, to give just one example, and a lot more elegant than the
stupidity in the C language with only "exit the innermost loop" construct.

GOTO is fundamental to computer programming.  the key is not to ban it, or
condemn it, but to invent better ways to express the uses to which it has
been and may be put.  it is not a coincidence that the languages that
purport to ban GOTO and variations like the C statements mentioned above,
are very hard to read because of the clutter introduced to get around the
lack of these features.  a major disservice to programmers and code
reviewers alike, in the name of some misunderstood religious cause.

one of the perhaps best examples of the need for the functionality of GOTO
without GOTO itself, is error processing.  IMNSHO, it makes much more sense
to "goto error_handler" than to do a lot of processing in the middle of a
function totally unrelated to processing errors in its assumptions about
the operating environment.  with languages that has the "return" statement,
this can effectively isolate the return points and _name_ them.  it is not
a coincidence that GOTO-less languages and GOTOphobic programmers don't do
error processing very diligently, and produce lots of code that violate
Microsoft's look-and-feel "patent" on machines that freeze and crash.

languages that lack the GOTO family of control statements, must have many
redeeming qualities to maintain a right to be called a _programming_
language, not just contestants in academic beauty pageants.  functional
programming languages satisfy this requirement in my mind, and I program
more in LISP than in any procedural language.  however, when I do program
in a procedural language, there's usually a GOTO for every 500 statements
or so.

should beginners be taught to avoid GOTO, or should we all strive not to
let beginners loose on production software?  programmers who don't know
when and how to use GOTO properly, will _remain_ beginners, and it is
better to teach them the reality of the world they will enter before they
end up with a lot of bad habits and stupid religious notions.  it's just
like PASCAL programmers who continue to write PASCAL programs in all known
programming languages, even LISP.  the desirability of an over-protective
upbringing is probably no higher for programmers than for other people.

best regards,
</erik>
--
Erik Naggum <[email-masked]> <[email-masked]>  |  memento, terrigena.
ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS  |  memento, vita brevis.

for information on SGML and HyTime, try ftp.ifi.uio.no:/pub/SGML first.